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can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The functions needed to provide a service application and its constituent Service Capabilities may be replicated in a 
number of domains that are interconnected to provide, for instance, a call. 

Service capabilities are indivisible units of interoperability between TIPHON systems. Using known Service 
Capabilities, interconnection agreements can specify the Service Capabilities for which the agreement holds. 

Service providers and equipment vendors can add value to service capabilities by enhancing them in their networks and 
equipment beyond the functionality defined by the standardized definition without adversely impacting interoperability. 



Introduction 

The approach being taken to standardization in TIPHON represents a departure from that used in the past for PSTN, 
ISDN and GSM. Its aim is to allow much greater scope for competition through innovation in the design of equipment 
and services. Its aim is also to provide adequate standardization to facilitate the operation of services across 
interconnected networks, even networks that use different technologies. The present document presents the initial core 
set of service capabilities envisaged to be required to enable Service Providers to offer services on TIPHON networks 
that may safely inter-work with existing PSTN services while enabling more advanced services to be subsequently 
developed. 

Figure 1 shows the relationship of the present document with other TIPHON release 3 deliverables. 
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Figure 1 : Relationship with other TIPHON release 3 documents 

TR 101 311 [2] provides the requirements on the transport plane, 

TS 101 878 (the present document) defines service capabilities that are used in the TIPHON Release 3 for a 
simple call, 

TS 101 882 [3] provides the Protocol Framework based on the TIPHON Release 3 architecture to implement the 
simple call service capabilities as defined in the present document, 

TS 101 315 [4] is an implementer's guide that shows how to use of the meta-protocol to realise the capabiUties as 
defined in the persent document, 

TS 101 883 [5] provides the protocol mappings for the ITU-T H-323 profile, 

TS 101 884 [6] provides the protocol mappings for the SIP profile, 

TS 101 885 [7] provides the protocol mappings for the ITU-T H-248 profile, 

TS 101 314 [10] provides the architecture and reference configurations for TIPHON Release 3. 
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Scope 



The present document forms part of TIPHON Release 3 and defines a set of Service Capabilities for the support of 
simple call service applications. 

Service Capabilities are indivisible technical functions that are used to support service applications. They are defined 
from a technical perspective as technical functions and not from a user's perspective as service elements. 

The Service Capabilities and their attributes have been defined so that they are capable of supporting a telephony simple 
call service application that is compatible with telephony as standardized in ETSI for PSTN and ISDN. 

Subsets of the service capabilities defined here can be selected for implementation in equipment and networks to 
support particular service applications. 

The service capabilities defined here may also be used for the support of service applications other than simple call. 

TR 101 835 [8] provides details of the steps involved in a TIPHON release. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

administrative domain: collection of physical or functional entities under the control of a single administration 

aggregate bearer: logical association of functional entities in an IP telephony application and Transport Network 
which creates one or more concurrent end to end media flows and which is not limited to the duration of a single call 

aggregate bearer admission control: functional entity that determines whether or not a flow is to be admitted as part 
of an established aggregate bearer 

aggregate bearer measurement function: functional entity that determines the capacity used and remaining in an 
aggregate bearer as a result of measuring the actual media flows after taking into account what flows were requested 

bearer: logical association of functional entities in an IP telephony application and Transport Network that creates an 
end to end media flow for no longer than the duration of a call 

domain: collection of physical or functional entities within an administrative domain that share a consistent set of 
policies and common technologies 

end-user: entity using the services of an IP telephony Service Provider or Transport Network operator 

end-user domain: collection of physical or functional entities under the control of an end-user that share a consistent 
set of policies and common technologies 

first party (call) clearing: first party to hang up, clears the call 

functional entity: entity in a system that performs a specific set of functions 

functional group: collection of functional entities within a domain 

NOTE: In TIPHON systems functional groups are used to structure the necessary functionality to offer IP 
telephony services across domains. 

gateway functional group: functional group containing the functionality of a network functional group also the 
functionality necessary to connect calls to the SCN 

NOTE: Gateway functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

home network functional group: functional group which is aware of the service application subscribed to by the end- 
user 

NOTE: Home network functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

information flow: interaction between a communicating pair of functional entities 

interface: shared boundary between two communicating systems, devices or equipment 

intermediate (transit) network functional group: functional group connecting the serving network functional group 
to the home network functional group 

NOTE: The intermediate network functional group is only present when the serving network functional group and 
the home network functional group are not directly connected. 

IP network: packet Transport Network comprising one or more transport domains each employing the IP protocol 

IP telephony: any telephony related service that is supported on an IP network 
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IP Telephony Service Provider (IPTSP): Service Provider providing IP telephony services 

NOTE: The same business entity may act as both a Transport Network operator and an IP telephony Service 
Provider. 

network: telecommunications network that provides telecommunications services 

network functional group: functional group containing the functionality required to establish a call between two 
terminals, a gateway and a terminal, or two gateways 

NOTE: Network functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

network operator: business entity operating a network 

number portability: ability of a user to change Service Provider or location without changing their E.164 number 

packet flow/transport flow: stream of packets of the same type identified by common address and port numbers 

NOTE: The stream may contain either signalling information or content description together with media 
information. 

private: indication of availability to a pre-determined set of users e.g. private network, private service 

protocol: set of semantics, syntax and procedures which govern the exchange of information across an interface 

public: indication of availability to the general public, e.g. public network, public service 

reference point: conceptual point at the conjunction of two communicating functional entities 

service: set of telecommunication related tasks performed for a customer by a Service Provider and supplied in a 
business context 

service application: way in which a number of service capabilities are combined to provide a service 

service capability: specified set of functionalities that are used to provide a component part of a service 

service domain: collection of physical or functional entities offering IP telephony services under the control of an IP 
telephony Service Provider which share a consistent set of policies and common technologies 

Service Provider: business entity that provides services to its customers on a contractual basis and is responsible for 
the services offered 

Service Provider identifier: globally unique identifier of a Service Provider (service domain) 

serving network functional group: functional group that enables terminal functional groups to connect to an IP 
telephony Service Provider 

Switched Circuit Network (SCN): telecommunications network, e.g. Public Switched Telephone Network (PSTN), 
Integrated Services Digital Network (ISDN), and General System for Mobile communications (GSM), that uses 
circuit-switched technologies for the support of voice calls 

NOTE: The SCN may be a public network or a private network. 

terminal: endpoint within the user equipment on which signalling and media flows originate and/or terminate 

terminal functional group: functional group representing all the IP telephony functionality within an end-user's 
terminal 

NOTE: Terminal functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call. 

terminal registration functional group: functional group representing the registration functionality within an end-user 
domain 

TIPHON compliant system: system that complies with the mandatory requirements identified in the TIPHON 
specifications 
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transport domain: collection of transport resources sharing a common set of policies, QoS mechanisms and transport 
technologies under the control of a Transport Network operator 

Transport Network: collection of transport resources which provide IP transport functionality 

Transport Network operator: business entity operating a Transport Network 

user identifier: information that enables an end user or access to be uniquely known 

user profile: service specific information about a user of a service application 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACR Anonymous Call Rejection 

ASN.l Abstract Syntax Notation no. 1 

BICC Bearer Independent Call Control 

CLI Calling Line Identification 

CLIP Calling Line Identification Presentation 

E.164 ITU-T Recommendation E.164 [13] 

GSM Global System Mobile 

H.323 ITU-T Recommendation H.323 [20] 

ICANN The Internet Corporation for Assigned Names and Numbers 

IP Internet Protocol 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

ITU International Telecommunications Union 

NFG Network functional group 

PSTN Public Switched Telephony Network 

QoR Query on Release 

RpoA Registration point of Attachment 

SCN Switched Circuit Network 

SIP Session Initiation Protocol 

SpoA Service point of Attachment 

SV Service 

TIPHON Telecommunications and Internet Protocol Harmonization Over Networks 

TN Transport Network 

ACQ All Call Query 

ECS Emergency Calling Service 

SP Service Provider 



Services and service capabilities 



4.1 



Introduction 



In ISDN and GSM, the approach to define services that were fully standardized gave little scope for innovation in the 
design of the services. This approach was ideally suited to "service inter-working", which was the main goal of the 
"public telephone service" and will be explained later. 

The technology and the market are now at a different stage of development. There is: 

• a common movement and convergence towards IP as the basic network technology; and 

• diversity in the protocols that can be used above the network layer with the prospect that SIP, H.323 and the 
various signalling systems from the circuit switched world being used in parallel. 

Therefore, there is a need for a methodical approach to inter-working between protocols. The market having reached 
relative maturity for simple voice communications is now starting a phase of new service development that is best led 
by commercial innovation. 
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TIPHON therefore has different objectives from those of the PSTN/ISDN/GSM and so is taking a different approach 
[9]. 

TIPHON is aiming to standardize modules of technical functionality that can be implemented using different protocols 
(technologies). This will enable operators and Service Providers to have their new, innovative and proprietary services 
supported across multiple networks because TIPHON provides standard units of functionality that can be referred to in 
the necessary interconnection agreements. 

TIPHON is NOT aiming to standardize any new service applications. 

NOTE 1 : The only service application being addressed by TIPHON Release 3 is the simple call service application. 
Because TIPHON is taking a new approach, it introduces some new terminology, the main new terms 
being "service application" and "service capability" (see clause 3.1). 

A service application is the technical description of a part of a service. One or more service applications, together with a 
commercial arrangement, form a service offering. From a technical perspective, a service application is capable of being 
offered as a service without any technical additions. A service application is described at least in part from the 
perspective of the user. 

A service capability is a unit of technical functionality that can be mixed-and matched to implement part of a 
(non-standardized) service application. It is important to understand that a service capability is defined only as a 
technical function from the perspective of network implementation and is not an element of service defined from the 
perspective of the user. Also the same service capability may be part of more than one service application (e.g. user 
registration or user profile) in one or more service offerings. 

Figure 2 illustrates the relationship between services, service applications and service capabilities. 



Savice - 



Sen/ice Application — 
Service Capability 




Commercial Context 



Figure 2: Services and service capabilities 



Service Capabilities may be used to build a hierarchy of functionality for service applications. This is illustrated in 
figure 3. A base service application (A) uses three standardized service applications. All service applications that use 
these three capabilities can interwork at this level of functionality (not shown on the diagram). Additional service 
applications are built by the same or different Service Providers by adding additional service capabilities. Where the 
same additional service capabilities have been added, e.g. the blue one added by both B and D, then the functionality for 
interoperability is enhanced. 
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Figure 3: Service application hierarchies 

NOTE 2: There will be a need for service level agreements for interconnection to specify the service capabilities 
supported by each Service Provider. 

The approach taken by TIPHON to describe the behaviour of the service capabilities in Release 3 is elaborated below. 
Object identifiers for each of these service capabilities are identified in annex A and functional groups are explained in 
annex C. 

For each service capability the following aspects are defined: 

• Purpose: a short description of the intention of the capability; 

• Attributes: relevant parameters that are variable for the purpose of standardization. This includes parameters that 
are signalled or set by management processes; 

• Normal behaviour: the high-level behaviour description in the normal case; and 

• Exceptional behaviour: the high-level behaviour description when the normal case cannot be met e.g. when 
faults occur or resources cannot be acquired. 

4.2 The simple call service application 

The simple call service application is defined so that the elements needed to support some of the standardized public 
telephone service that is offered on PSTN/ISDN/GSM are available. The public telephone service can be offered over 
new technologies, but the TIPHON simple call service application is less prescriptive and allows the support of 
enhancements of simple call that are outside the scope of the services defined for PSTN/ISDN/GSM. 

The service capabilities that have been defined and can be used by simple call have been defined so that they provide 
the functionality necessary for the support of the public telephone service. 
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4.3 Impact of unique services on roaming 

In the TIPHON approach, each Service Provider creates their own service offering. This service offering will consists of 
any number of service applications possibly bound by one user name. 

In deployments where a user may roam on other networks, the visited network may not understand the particulars of 
service application that users wish to use and may even not understand the naming scheme used, and in this case the 
visited network will treat signalling and media differently. The visited network will relay all signalling back to the home 
domain, but will manage locally the creation of bearers and provide quality control as appropriate. 

For some service applications such as public telephony, it may be necessary for visited networks to support some 
additional functionality such as emergency calls because this essential service needs to be provided locally since it 
requires access to local information and/or local points of connection. 

4.4 Interconnection and interoperability 

A basic distinction is made between services and transport, resulting in three levels of interconnection: 

• Service level interconnection, where the same service is presented by the interconnected networks and enables 
the users of the two different Service Providers to communicate with each other; 

• Roaming level interconnection, where the service is presented only by the home Service Provider but enables its 
users to use their services when roaming on another network; 

• Transport level interconnection, which enables a Service Provider to run its service over a transport level 
infrastructure provided by different operators. 

These are best explained by example. 

A Service Provider (SPl) defines and offers a Service (SVl) on a Transport Network (TNI). All customers of SPl who 
subscribe to service SVl can intercommunicate with each other and access that service from any point on TNI because 
TIPHON defines an on-line registration capability. 

The operator of TN 1 may decide to use transport level interconnections with other networks to link different part of its 
own network. These agreements will need to specify some level of transmission quality in order to support the quality 
that TNI requires. These interconnections will be invisible to the service level, as they all appear to be part of TNI. 

Suppose transport provider TNI, with agreement from SPl, implements a roaming level interconnection agreement 
with another network TN2. The customers of SPl can use their service SVl from anywhere on TNI or TN2. As more 
roaming level interconnection agreements are concluded, customers can access the service from more networks. 
However they can only use the service SVl to communicate with other customers of SPl, and not with customers of 
other Service Providers (SP2, SP3 etc) who are based on the other networks TN2, TN3 etc. Roaming level 
interconnection therefore extends the accessibility of a service but not the set of other parties that can be communicated 
with. This is illustrated in figure 4. 
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SV1 



SV2 



Customers of SV1 can roam anywhere in TNI and TN2 



but cannot communicate with customers of SV2 




Roaming level interconnection 

Figure 4: Effect of roaming level interconnection 

If, however, SPl concludes service level interconnection with SP2/TN2 for SVl, then the set of customers who can 
communicate with each other is increased to include the customers of SP2. Service level interconnection increases the 
set of other parties that can be communicated with. The functionality is limited to the common set of service capabilities 
between SPl and SP2. This is illustrated in figure 5. 



SVl 



SV2 



Customers of SVl and SV2 can roam anywhere in TN1 and TN2 



and can communicate with each other 




Service level interconnection 
Figure 5: Effect of service level interconnection 

The agreement for service level interconnection will need to specify: 

• A common base service application or applications that will be inter-worked; 

• Common standardized service capabilities at the service level together with the values of any particular 
parameters (e.g. a form of profile); 

• Any additional common but non-standardized functionality at the service level; 

• A common naming scheme with a coordinated system for allocating names to users; 

• A Service Provider identity that the roaming user will use at registration time; 
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• An agreed naming scheme for identifying each network (for routing, it is necessary to determine the home 
network name from the called user name); 

• The technology (protocols) for implementing the interconnection. 

Together with the relevant quality of service values and the commercial arrangements. 
The agreement for roaming level interconnection will need to specify: 

• Service capabilities needed for the roaming users along with parameters that may be prescribed or signalled 
during service usage; 

• A Service Provider identity that the roaming user will use at registration time; 

• Service applications that are to be resolved locally (such as emergency calls); 

• The technology (protocols) for implementing the interconnection. 

Together with the relevant quality of service values and the commercial arrangements. 
The agreement for transport level interconnection will need to specify: 

• Any non-standardized functionality at the transport level that is the subject of innovation; 

• Technology (Protocols) e.g. IP or ATM used to implement the inter-domain transport and signalling. 
Together with the relevant quality of service values and the commercial arrangements. 

There are three types of functional grouping defined in the TIPHON architecture [10]: 

• Originating functional group; 

• Intermediate (transit) functional group; 

• Terminating functional group. 

The description of the service capabilities in the present document refer to these functional groupings where they 
depend on the type of functional grouping (e.g. for service capability X, the originating functional group shall do Y and 
the intermediate functional group shall do Z). 



4.5 Naming strategy 



The choice of the naming scheme to be used is an important part of the specification of a service because the choice of 
naming scheme places an absolute limit on the set of entities that can be communicated with. 

Also, any network that provides the service or provides service level interconnection needs to be able to resolve the 
names used into addresses using information obtained from registration. For roaming level interconnection, this does 
not apply. 

Call set-up and some other service capabilities involve names. For call set-up, at least these names have to be resolved 
into addresses for routing. This can occur in several stages by networks with service level interconnection but is 
performed finally by the terminating Home network. All these networks need to be able to understand the naming 
scheme used (for this user). The final resolution needs to use information obtained during the registration process of the 
terminating user. A home network will have this information for its own customers as a result of their registration, but 
will not have this information for users normally registered with an interconnected network. In order to set up calls to 
customers of an interconnected network, a service level interconnection is needed. This must ensure that customers can 
be identified by names, allowing the interconnected network to use its own registration information for resolving these 
names to addresses. 

In contrast, roaming level interconnection only extends the reach of registration and thus the home Service Provider can 
still resolve the names of its customers to addresses on the visited networks. Thus roaming level interconnection does 
not require the support of the same naming scheme and only requires knowledge of addresses. 
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Naming schemes are not specified in the definition of the service capabilities, thus where service capabilities involve 
naming they can be used with any naming scheme, although the choice of naming scheme is an essential part of the 
service application. Some service capabilities, however, (e.g. number portability) apply only to the support of specific 
naming schemes (e.g. E.164). 

The three naming schemes available to be considered at present are: 

• Public telephony numbers E.164 defined by ITU; 

• Internet names defined by ICANN; and 

• Unspecified private naming schemes. 

TIPHON has produced TR 101 326 [11] which explains how name to address resolution is to be handled for E. 164. It 
has also produced TR 101 858 [12] which gives more information on Number Portability and its implication for 
TIPHON networks. These documents should be read in conjunction with the present document. The support of E.164 is 
essential for the support of public telephony and for interworking with the PSTN/ISDN/GSM. 

The support of Internet naming is deferred to a later Release. 



4.6 Naming in TIPHON Release 3 



TIPHON Release 3 Public Telephony is based on the use of numbering plans derived from the application of ITU-T 
Recommendation E.164 [13]. Exceptions are numbering schemes used in private networks and service codes such as 
carrier selection code and emergency number. 



5 Registration service capabilities 

5.1 Terminal transport service registration 

Purpose: 

To establish a temporary logical association between a Terminal functional group requesting transport layer services 
and a network functional group providing such services. 

Attributes: 

«List of Registration point of Attachments»; The address(es) returned by the terminal functional group on successful 
Terminal Registration. 

Normal behaviour: 

A Terminal functional group shall supply the terminal name for terminal address allocation. 

On successful terminal transport service registration, the Registration point of Attachment (RpoA) shall be provided to 
the terminal function group. 

The entity at the RpoA shall act as proxy for the TIPHON registration process. 

The RpoA shall act as the SpoA for the emergency service (where offered). 

Exceptional behaviour: 

If Terminal Transport Service Registration fails, or an RpoA is not obtained (or known), the behaviour is beyond the 
scope of the present document. 
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5.2 User service registration 

Purpose: 

To establish a temporary logical association between a User, a terminal functional group, a serving network functional 
group and a service domain for the purposes of gaining access to TIPHON communication services. 

Attributes: 

«service point of attachment (SpoA)»; The SpoA is the address returned by the home network functional group on 
successful User Registration. 

«registering user identifier»; The user identifier of the user who is performing service registration. 

«ticket»; Information that a user may pass when requesting services from a service application. 

«user profile»; The user profile contains information specific to the user that is relevant to the provision of services. 

«duration»; For each authorized capability, the user profile shall contain the duration for which the authorization is 
valid. 

Normal behaviour: 

A Terminal functional group shall supply credentials for registration. 

A Terminal functional group shall supply service applications for which the registration shall be used (for example, for 
the simple call) as well as properties for that service application (like user identifier to be used). 

The Home network functional group shall hold a terminal/user status & authorized capabilities maintained as a user 
profile. For each authorized capability, the user profile shall contain the duration for which the authorization is valid 
and a SpoA where that authorization is valid. 

The Home network functional group shall supply a ticket for use by the user for subsequent uses of the requested 
service application. 

The Home network functional group shall determine those capabilities that the registering user may use and maintain 
them in the user profile. 

Registration shall be performed by the home network functional group. 

If the terminal receives a successful registration for an emergency service application, that registration shall be used in 
preference to the implicit emergency service application provided at the RpoA. 

Exceptional behaviour: 

The RpoA shall continue to act as the SpoA for the emergency service (where offered). 

If registration fails, the registering user shall be notified in an appropriate manner. 

Where service applications are requested, the rejected Service applications are not available. 

5.3 Public telephony carrier selection 

Carrier selection includes selection by the user on a call-by-call basis and pre-selection where the user's selection is 
stored in the network. 

5.3.1 Per-call carrier selection 

Purpose: 

This relates to a capability to determine which carrier shall be used to convey a call wherever a choice of that carrier is 
possible. Carrier selection is performed by the user on a call-by-call basis. 
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Attributes: 



«Service Provider Identity»; The carrier that is to be selected shall be indicated using a Service Provider Identity 
which is entered by the user as a prefix to the called number. 

Normal behaviour: 

A user may indicate a choice of carrier for the onward conveyance of a particular call. This shall be signalled on a per 
call basis. The means of making the per-call request shall be determined by the originating serving network functional 
group [9]. 

Per-call carrier selection shall override any active carrier pre-selection and the call shall be routed according to the user 
indicated carrier selection. 

NOTE: Signalling systems designed according to TIPHON specifications shall permit the conveyance of an 
indication of the user's choice between functional groups engaged in the establishment of a call. The 
values used to convey the user's choice shall be a national and interconnect matter. 

All functional group's which understand the user's preference and can comply with the preference expressed shall do so; 
the principal responsibility in this regard lies with the originating users Home functional group. 

Exceptional behaviour: 

Where the carrier indication received from the user is invalid the call shall fail. 

Where a call cannot be completed at a network functional group because use of the requested carrier will not allow 
completion of the call, the call shall fail. 

5.3.2 Carrier pre-selection 

Purpose: 

This service capability applies to Release 3 where E.164 is used as the naming scheme. This relates to a capability to 
determine which carrier shall be used to convey a call based on a pre-selection which is stored in the network. 

Attributes: 

«Service Provider Identity»; The carrier that is to be selected shall be indicated using a Service Provider Identity. 

Normal behaviour: 

A user may indicate a choice of carrier for the onward conveyance of calls using a default setting in the user profile. 
The default behaviour shall be to use the pre-selected carrier if one has been nominated. The means by which the 
pre-selected carrier is chosen is network specific. The pre-selected choice of carrier is an attribute of the originating 
home functional group. This attribute may be conveyed to the originating serving network functional group at the time 
of registration. 

If a per-call override of the pre-selection is requested, the call shall be routed according to the user indicated carrier 
selection. The means of making the per-call request shall be determined by the originating serving network functional 
group [9]. 

NOTE: Signalling systems designed according to TIPHON specifications shall permit the conveyance of an 
indication of the user's choice between functional groups engaged in the establishment of a call. The 
values used to convey the user's choice shall be a national and interconnect matter. 

All functional group's which understand the user's preference and can comply with the preference expressed shall do so; 
the principal responsibility in this regard lies with the originating users home functional group. 

Exceptional behaviour: 

Where the carrier indication received from the user is invalid the call shall fail. 

Where a call cannot be completed at a network functional group because use of the requested carrier will not allow 
completion of the call, the call shall fail. 
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6 Call Connectivity service capabilities 

6.1 Simple call establishment 

Purpose: 

To establish a call between a calling entity and called entity for the purpose of conveying information. 

Attributes: 

«caUed user identifier»; A user shall supply a called user identifier corresponding to another user to whom a 
connection is desired. In the case of public telephony this is an E.164 address. 

«failure reason»; Information that identifies the reason for failure to establish a call. 

«target transit network identity »; The target transit network identity shall be used to inform the next-hop network 
functional group how to route the call. 

Normal behaviour: 

If per-call carrier selection is invoked, the Service Provider identity shall be included as a prefix in the call set-up 
request from the user. 

A target transit network identity shall be used to inform the next-hop NFG how to route the call. 

Simple call establishment forms a temporary logical association between originating and terminating users for the 
purpose of information transfer. The association is established across each of the functional groups involved. 

During the creation of this association: 

• The originating NFG shall set the target transit network identity to the value of the home NFG of the calling user 
and use this value to route the call. 

• Any intermediate NFG shall use the target transit network identity value to route the call. 

• The originating home NFG shall route the call as informed by the called party identity (possibly using the 
resolution service capability), the target transit network identity may be modified by the home network to reflect 
the terminating home network. 

• The terminating home NFG may modify the target transit network identity to reflect the terminating visited 
network (possibly based on the presence service capability) and use this value to route the call. 

• The terminating network shall route the call to the terminating terminal (possibly based on the presence service 
capabihty). 

Upon request of either user, the temporary logical association between originating and terminating users is removed. 
The association is removed from each of the functional groups involved. 

Exceptional behaviour: 

If an association with a terminating user cannot be established, the originating user shall be notified in an appropriate 
manner. 

If a failure is detected within any functional group, the association shall be removed in each functional group involved 
and any associated resources released. The functional group that detects the failure shall supply a. failure reason for the 
failure to each other functional group. 

The failure mode behaviour for this capability shall be to always remove any existing association and release any 
associated resources. 
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6.2 Calling user identity generation 

Purpose: 

To generate a user identifier consistent with the naming scheme of the service that is being supported. In the case of 
pubHc telephony calls, this shall be a telephone number consistent with the international public telecommunication 
numbering plan [13]. 

To generate a terminal equipment identifier which may serve to uniquely identify the calling equipment to public 
networks. 

This Service Capability shall apply at Home network functional groups. 

For TIPHON Release 3 where E.164 is used as the identification scheme, this service capability is equivalent to the 
implied capabilities needed to support CLIP in ISDN and its equivalent in the PSTN [14]. 

Attributes: 

«calling user identifier»; For TIPHON Release 3, the calling user identifier is a telephone number that may be sent 
to called users in order to identify the calling user and allow them to return a call using it. Where E.164 names are 
supported, the Home functional group shall hold a default calling user identifier. 

«additional calling user identifier»; The Home functional group may also hold an additional calling user identifier, 
which is the user identifier which may be sent to called users in order to identify the calling user and allow them to 
return a call using it. The additional calling user identifier is only used where it is not the same as the calling user 
identifier. 

«equipment identifier»; The equipment identifier is provided by the Terminal Equipment. It may be conveyed as an 
additional calling user identifier. 

NOTE 1 : See clause 6.4 for calling user identity delivery including use of additional calling user identifier. 

«presentation restriction indicator»; The calling user identifier and the additional calling user identifier shall each 
have an associated presentation restriction indicator which may take values representing the following meanings: 

• presentation allowed; 

• presentation restricted; 

• number not available. 

The default presentation restriction indicator associated with the additional calling user identifier shall use the value 
meaning presentation allowed. 

« screening indicator»; The default calling user identifier and the additional calling user identifier shall each have a 
screening indicator which may take values representing the following meanings: 

• user provided, not verified; 

• user provided, verified and passed; 

• network provided. 

The default screening indicator associated with the calling user identifier shall use the value meaning 'network 
provided'. 

The default screening indicator associated with the additional calling user identifier shall use the value meaning 'user 
provided, verified and passed'. 

« nature of address indicator»; For TIPHON Release 3 where E.164 is used as the identification scheme, the calling 
user identifier and the additional calling user identifier shall each have a nature of address indicator which may take 
values representing the following meanings: 

• National (significant) number; 

• International number. 
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«number complete indicator»; The calling user identifier and the additional calling user identifier shall each have a 
number complete indicator which may take values representing the following meanings: 

• Number Incomplete; 

• Number Complete. 

The default number complete indicator associated with both the calling user identifier and the default additional calling 
user identifier shall use the value meaning the number is complete. 

«current/next presentation restriction indicator»; The home functional group shall hold a current/next presentation 
restriction indicator which indicates for the present call, where a call is currently established or being established, or for 
the next call made whether the user wishes calling line identity to be presented or restricted. 

«successive presentation restriction indicator»; The home functional group shall hold a successive presentation 
restriction indicator that indicates whether the user wishes that calls after the current/next shall have calling line identity 
presented or restricted. 

«Generic Identifie r»(optionaiy, One or more instances of generic identifier may be generated. Each will contain two 
sub attributes: 

• Type which may convey the meanings: 

Account code; 
Authorization code; 
Private network travelling class mark; 
Business communication group identity; 
and; 

• Identifier (which may be a number) 

NOTE 2: These attributes are provided for the purpose of inter- working with any public network that uses IS UP or 
BICC for interconnection and are specified to be compatible. 

Normal behaviour: 

NOTE 3: For explanation, there are two number fields by which a caller may be identified in signalling: 

calling user identifier; and 

additional calling user identifier; 
but there are three potential sources of data to use in these fields: 

a number supplied by the user on a per-call basis; 

a default number stored as the calling line identity by the home network functional group and 
validated by the network operator; and 

a number stored as the additional calling user identifier, which is chosen by the user subject to certain 
limitations. 

The following description of behaviour specifies which source is used for which number field in outgoing signalling 
under different circumstances. 

The Home functional group may receive a calling user identifier from the caller on a per call basis. 

If this calling user identifier is received from caller without a special arrangement, it shall be screened using: 

• a range of numbers which are valid for the caller, or 

• a list of numbers associated with the caller, or 
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• some other procedure to determine whether the user supplied number is correct. 

If the received calling user identifier is found to be valid, the screening indicator associated with that number shall be 
set to user provided, verified and passed. 

If the calling user identifier is received from a caller with a special arrangement, the home functional group shall set the 
screening indicator associated with that number to user provided, not screened. 

The home functional group shall ensure that the nature of address indicator and the number complete indicator are 
appropriately set on all numbers sent to other functional groups. The number complete indicator may be set to number 
incomplete only where the user has supplied a number which was found to be incomplete when it was screened. 

If no calling user identifier is received from the caller, the home functional group shall use the default calling user 
identifier as the calling user identifier in signalling to any subsequent functional group. 

If the home functional group receives a calling user identifier from the calling user and the home functional group has 
stored a default additional calling user identifier then the additional calling user identifier is used instead of the 
received calling user identifier in signalling to any subsequent functional group. 

If the home functional group is to behave as if a calling user identifier was received, whether or not it was supplied by 
the calling user, the received calling user identifier shall be forwarded to other functional groups as the additional 
calling user identifier. 

The home functional group shall forward the default calling user identifier to other functional groups as the calling user 
identifier. 

The home functional group shall not alter the value of presentation indicators supplied by the user. 

Where either of the calling user identifiers is derived from one of the default attributes, the state of the presentation 
restriction indicator may be altered in accordance with the current/next presentation restriction indicator. The state of 
the current/next presentation restriction indicator shall be set to the value of the successive presentation restriction 
indicator at the end of a call. 

The home functional group of the terminating user shall not forward to another functional group any calling user 
identifier or additional calling user identifier which has an indicator which indicates that presentation is restricted. 

However, where certain special agreements exist, the Home functional group (which must also be the serving and 
terminating functional group) may pass the calling user identifier and additional calling user identifier unchanged to 
the called party. 

NOTE 4: The restriction that such terminating special arrangements apply only to co-incident home, serving and 
terminating functional groups is applied because of privacy restrictions where the user has requested no 
release of calling user information. 

Exceptional behaviour: 

If a fault prevents a calling user identifier from being made available, the home functional group shall set the 
presentation restriction indicator passed to other functional groups to the value number not available. 

6.3 Calling user identity conveyance 

Purpose: 

This service capability applies to the conveyance of calling user identity information at all functional groups other that 
those acting as home functional groups. 

NOTE: For TIPHON Release 3 where E.164 is used as the identification scheme, this service capability is 

equivalent to the implied capabilities needed to support CLIP in ISDN and its equivalent in the PSTN. 

Attributes: 

«calling user identifier»; The calling user identifier is the telephone number that should be sent to telephone users in 
order to identify the calling user For TIPHON Release 3 where E.164 names are supported, the home functional group 
shall hold a default calling user identifier. 
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«presentation restriction indicator»; The indicator to be associated with the calling user identifier. 

«additional calling user identifier(s)»; The home functional group may also hold an additional calling user 
identifier, which is the user identifier which should be sent to end users so that they may return a call using it. The 
additional calling user identifier is only used where it is not the same as the calling user identifier. 

«presentation restriction indicator»; The indicator to be associated with the additional calling user identifier(s). 

Normal behaviour: 

A Serving functional group or a Transit functional group shall not alter, in whole or in part, the calling user identifier or 
the additional calling user identifier or any sub-attribute thereof except for withholding CLI when requested or to adjust 
the number so it is diallable by the called party. 

Exceptional behaviour: 

None identified. 

6.4 Calling user identity delivery 

Purpose: 

This service capability applies to the terminating network functional group only. It is concerned only with the delivery 
of calling line identity information to the user's terminal or into the SCN. 

NOTE: For TIPHON Release 3 where E.164 is used as the identification scheme, this service capability is 
equivalent to the CLIP in ISDN [14] (see references ...) and its equivalent in the PSTN. 

Attributes: 

«calling user identifier»; 

«presentation restriction indicator»; The indicator to be associated with the calling user identifier. 

«additional calling user identifier(s)»; The Home functional group may also hold an additional calling user 
identifier, which is the user identifier which should be sent to end users so that they may return a call using it. The 
additional calling user identifier is only used where it is not the same as the calling user identifier. 

«presentation restriction indicator»; The indicator to be associated with the additional calling user identifier(s). 

Normal behaviour: 

The terminating functional group may receive both calling user identifier and additional calling user identifier. If an 
additional calling user identifier is present it shall be forwarded to the terminal if the presentation restriction indicator 
permits. If only the calling user identifier is available then it shall be forwarded to the terminal if the presentation 
restriction indicator permits. In special circumstances such as emergency services, the CLI may be presented regardless 
of the presentation restriction indicator. 

If both calling user identifier and additional calling user identifier are present and the terminal is connected using a 
signalling system capable of conveying more than one calling user identifier then both numbers shall be forwarded 
subject to the presentation restriction indicators for each number. 

Terminals should normally be made aware of the difference between callers whose number is not available for technical 
reasons and callers who choose to withhold their number. 

The behaviour in this service capability is subject to amendment by national and local laws and regulations and acts as a 
template for behaviour which offers performance to end users which is consistent with the SCN. 

Terminating gateways shall modify telephone numbers and the nature of address indicator in both the calling user 
identifier and additional calling user identifier as necessary to conform with the conventions used in a connected SCN. 
However the gateway shall not change the screening indicator, number complete indicator or presentation restriction 
indicators. Notwithstanding, terminating gateways may amend telephone numbers and set the presentation restriction 
indicator to 'number not available' if it is demanded by local requirements. 
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Originating gateways shall modify telephone numbers and the nature of address indicator in both the calling user 
identifier and additional calling user identifier as necessary to conform with the conventions used in a connected SCN. 
However the gateway shall not change the screening indicator, number complete indicator or presentation restriction 
indicators. Notwithstanding, originating gateways may amend telephone numbers and set the presentation restriction 
indicator to 'number not available' if it is demanded by local requirements. 

Exceptional behaviour: 

Under fault conditions which prevent calling numbers being determined, the user shall receive an indication with 
number not available unless local or interconnect agreements demand otherwise. 

The calling user identifier or the additional calling user identifier shall be removed if the restriction information cannot 
be conveyed. 

6.5 Call rejection 

Purpose: 

This service capability applies to a user served by a home terminating network functional group. The procedures for 
creation and establishing or changing values of attributes is outside the scope of the present document. 

For TIPHON Release 3 where E.164 is used as the identification scheme, this service capability is equivalent to the 
implied capabilities needed to support ACR as specified in [15] for the PSTN. 

Attributes: 

call rejection indication» (optional); The call rejection indication has a value associated with the cause of rejection. 

Normal behaviour: 

If a terminating functional group receives a request to establish a call to a user where: 

• the call rejection indication is present and set; and 

• either; 

If the additional calling user identifier is present and the associated presentation restriction indicator is set to 
presentation restricted; or 

If only the calling user identifier is present and the associated presentation restriction indicator is set to 
presentation restricted; 

then the terminating functional group shall refuse the call giving an indication that the call was rejected 
because of anonymous call rejection. 

Originating gateway functional groups shall map the refusal information in accordance with the signalling system 
capabilities and appropriate TIPHON specifications subject to local requirements and agreements. 

Exceptional behaviour: 

None identified. 



6.6 Number portability 



TR 102 081 [16] defines four number portability routeing techniques. All call query, query on release, call dropback, 
and onward routeing. These techniques are defined in terms of routeing between networks rather than within networks. 
The Service Resolution defined in annex B can be used to support number portability depending on the data available. 
In the present document, onward routing is not specified as a service capability because it does not affect the signalling 
between networks and so may be implemented with only the functions specified in annex B. TR 101 858 [12] gives 
more information on number portability and its implication for TIPHON networks. 
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6.6.1 Number portability - All call query 

Purpose: 

This number portability - All Call Query (ACQ) service capability applies to TIPHON Release 3 where E.164 is used as 
the naming scheme. The choice of Number Portability method may be specified by regulation. 

NOTE: TR 101 858 [12] explains how number portability can be implemented in TIPHON networks. Although 
this Technical Report also includes query on release and dropback, these alternative methods apply only 
between networks. 

Attributes: 

«caUed user identifier»; A user shall supply a called user identifier corresponding to another user to whom a 
connection is desired. In the case of parties that are only available via an SCN, this is an E.164 address. 

«routing number»; A routing number is determined from a called user identifier. It shall be possible to indicate one 
or more of the following destinations with a routing number ported to the SCN: 

i) Recipient Network ID (RNID); and/or 

ii) Point of Interconnection (POI); and/or 

iii) Recipient Exchange (REX). 

It shall be possible to indicate one or more of the following destinations with a routing number ported to an IP 
Telephony provider: 

i) Service Provider Identity; and/or 

ii) Point of Interconnection (i.e. an IP address and port); and/or 

iii) Recipient network functional group. 

Normal behaviour: 

A network functional group shall determine whether the user identifier of the called party should be queried for number 
portability purposes. If it should be queried, the network functional group shall establish the routing number associated 
with the called user identifier. 

When a network functional group has established a routing number associated with the called user identifier, it shall be 
possible to transfer both the unchanged called user identifier and a routing number unambiguously. 

The routing number shall be used to inform the routing decision at any network functional group where it is available. 
Where a network functional group which has already taken part in call routing transfers the routing number to another 
network functional group, that group shall use the routing number to inform the routing decision. 

Exceptional behaviour: 

When, because of a fault, the routing number cannot be determined routing should proceed as if no routing number was 
apphcable. 

6.6.2 Number portability - Query on release 

Purpose: 

This number portability -Query on Release (QoR) service capability applies to TIPHON Release 3 where E.164 is used 
as the naming scheme. The choice of number portability method may be specified by regulation. 

Attributes: 

«called user identifier»; A user shall supply a called user identifier corresponding to another user to whom a 
connection is desired. In the case of parties that are only available via an SCN, this is an E.164 address. 
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«routing number»; A routing number is determined from a called user identifier. It shall be possible to indicate one 
or more of the following destinations with a routing number ported to the SCN [16]: 

i) Recipient Network ID (RNID); and/or 

ii) Point of Interconnection (POI); and/or 

iii) Recipient Exchange (REX). 

It shall be possible to indicate one or more of the following destinations with a routing number ported to an IP 
telephony provider: 

i) Service provider identity; and/or 

ii) Point of interconnection (i.e. an IP address and port); and/or 

iii) Recipient network functional group. 

«query on release capability»; A network functional group which is capable storing the information needed for and 
executing and acting upon a query on release request shall indicate the fact using a query on release capability 
indication. 

Normal behaviour: 

A Home Terminating functional group shall determine if a called user identifier represents a ported number. If it is 
ported, it shall send a Query on Release request to the network functional group from which it received the request to 
establish a call. 

An originating and an intermediate functional group that can execute and act on a query on release shall indicate this to 
the next network functional group to which information is passed. An intermediate network functional group, which has 
itself got query on release capability, shall store the information needed to make the query until the call is either 
established or the call is released. The release may be accompanied by an indication that the called user identifier 
represents a ported user. 

When a network functional group receives an indication that the called user identifier represents a ported user, and the 
preceding network functional group indicates no query on release capability, the recipient shall perform a query to 
establish the routing number associated with the called user identifier. Any resources reserved for the original routing 
before an indication of porting was received shall be released. 

When a network functional group receives an indication that the called user identifier represents a ported user, and the 
preceding network functional group indicates it has query on release capability, the recipient shall pass the query on 
release request to the preceding network functional group. Any resources reserved for the original routing before an 
indication of porting was received shall be released. 

When a network functional group has established a routing number associated with the called user identifier it shall be 
possible to transfer unambiguously both the unchanged called user identifier and a routing number. 

The routing number shall be used to inform the routing decision at any network functional group where it is available. 
Where a network functional group which has already taken part in call routing transfers the routing number to another 
network functional group, that group shall use the routing number shall be used to inform the routing decision. 

Exceptional behaviour: 

When, because of a fault, the routing number cannot be determined routing the call shall fail with an appropriate 
indication that the caller should try again later. 

If a query on release request is received at a network functional group and there is no preceding network functional 
group which has indicated that it has query on release capability, then the call shall be released without a specific 
reason. 
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6.6.3 Number portability - Pivot routing (Dropbacl<) 

Purpose: 

This number portability - Pivot routing (Dropback) service capability applies to TIPHON Release 3 where E.164 is used 
as the naming scheme. The choice of Number Portability method may be specified by regulation. 

Attributes: 

«called user identifier»; A user shall supply a called user identifier corresponding to another user to whom a 
connection is desired. In the case of parties that are only available via an SCN, this is an E.164 address. 

«routing number»; A routing number is determined from a called user identifier. It shall be possible to indicate one 
or more of the following destinations with a routing number ported to the SCN (Source: TR 102 081 [16]): 

i) Recipient network identity; and/or 

ii) Point Of Interconnection (POI); and/or 

iii) Recipient EXchange (REX). 

It shall be possible to indicate one or more of the following destinations with a routing number ported to an IP 
telephony provider: 

i) Service provider identity; and/or 

ii) Point Of Interconnection (i.e. an IP address and port); and/or 

iii) Recipient network functional group. 

A network functional group that is capable executing a pivot routing request for the purposes of number portability shall 
be said to have pivot routing capability. 

Normal behaviour: 

If a network functional group has pivot routing capability, then it shall indicate that fact to the next network functional 
group involved in routing the call. The indication may be by call signalling or otherwise. 

A Home terminating functional group shall determine if a called user identifier represents a ported number. If the 
preceding network functional group has pivot routing capability, then the home network functional group shall invoke 
pivot routing and pass the routing number to the preceding network functional group. 

If an intermediate functional group receives the pivot routing invocation, and a preceding network functional group has 
indicated /?/vof routing capability, the invocation is passed to that functional group. Having passed the invocation to the 
preceding network functional group all reserved resources for the call are released. 

If an intermediate functional group receives the pivot routing invocation, and no preceding network functional group 
has pivot routing capability, the receiving network functional group shall execute pivot routing using the received 
routing number. All reserved resources for original call are released. 

If the originating functional group receives the pivot routing invocation it shall execute pivot routing using the received 
routing number. All reserved resources for the original call are released. 

When the call is established using the routing number both that number and the called party user identifier shall be 
passed unambiguously to each successive network functional group and shall inform each subsequent routing decision. 

Exceptional behaviour: 

If a pivot routing invocation request is received at a network functional group which does not itself have pivot routing 
capability and no preceding network functional group has pivot routing capability, then the call shall be released 
without a specific reason. 



£75/ 



29 ETSI TS 1 01 878 V1 .1 .1 (2002-02) 

6.7 Emergency calls 

Purpose: 

The Emergency Calling Service (ECS) enables members of the general public to initiate emergency calls using fixed 
calling numbers, e.g. 1 12, 999, 91 1, to an emergency services centre or to other agencies that are treated as emergency 
services. These calls require no user authentication and would not normally require payment by the caller. 

Attributes: 

«priority»; This capability requires the priority of the call to be discernible either through explicit signalling or 
through identification of the called user identity (i.e. service code). 

Normal behaviour: 

Emergency calls from end-user functional groups are recognized by the use of nationally and locally specified service 
codes or by sending special indications. 

Emergency calls from other network functional groups are recognized by the service code or through explicit signalling. 

Emergency calls from users who are not registered with a Home functional group may be handled as a per domain 
option. 

Emergency calls shall be routed in accordance with the nationally agreed plan for this service capability. 

Emergency calls shall be completed in preference to any normal calls that may compete for resources. 

Emergency calls shall be completed as soon as possible if all resources are busy. 

Emergency calls shall be exempted from any restrictive management routing controls. 

Exceptional behaviour: 

Under conditions of restoration after faults, emergency calls shall be restored with priority over normal calls. 

6.8 Authorized emergency priority calls 

Purpose: 

The authorized Emergency Telecommunications Service (ETS) enables specific users to make priority calls to any 
destination from any served point for supporting recovery operations during disaster events. 

This service applies to TIPHON Release 3 where E.164 is used as the naming scheme. The handling of Priority calls 
described here is intended to meet the Essential features on the ITU International Emergency Preference Scheme (lEPS) 
as defined in ITU-T Recommendation E. 106 [21] and the ITU-T International Emergency Multimedia Service (lEMS) 
as defined in ITU-T Recommendation F.706 [22]. 

Procedures for deciding on which users may use the ETS service, how to activate and de-activate ETS for a user, 
domain or administrative domain are outside the scope of the present document. 

Attributes: 

«ETS user indication»; Authorized Users that are to be treated with preference may have an ETS user indication set 
to true. An attribute ETS user indication may also be assigned to a particular call. 

Normal behaviour: 

During registration the originating functional group may optionally be informed if a user has the ETS user indication 
set. This option is used if the serving functional group and or transit functional groups are subject to the active ETS. The 
use of this facility may have security implications that must be taken into account before using the option. 

Within a Home functional group, a user with lEPS user indication shall be given preferential treatment in the allocation 
of resources. Such preferential treatment shall not extend to pre-emption of resources allocated to established calls. 
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At the Home functional group calls from users with ETS user indication shall not be subject to any restrictive 
management controls such as call gapping. 

Calls from a Home functional group forwarded to another functional group signalling shall indicate that the call is to be 
handled in accordance with ETS criteria. 

Calls received at any network functional group where signalling indicates that the call is to be handled in accordance 
with ETS provisions shall be given preferential treatment in the allocation of resources. Such calls shall not be subject 
to any restrictive management controls such as call gapping but special treatment shall not extend to pre-emption of 
resources allocated to established calls. 

The preferential treatment given on establishment of the call shall also extend to a preference in the allocation of all 
resources including transport resources. Preferential allocation of resources in the transport layer which may affect 
usability shall be given to calls with ETS user indication, the means of achieving this may vary between domains but 
should be assured between domains by appropriate means. 

Exceptional behaviour: 

Under fault conditions when restoration occurs functional groups may give preferential establishment to calls with ETS 
user indication set to true, this may extend to the transport layer. 



7 Bearer connectivity service capabilities 

7.1 Bearer creation 

Purpose: 

To establish a transmission path between two functional groups for the purpose of creating a media bearing flow 
(bearer) between them for use within a call. 

Attributes: 

The functional group requesting the bearer shall supply a signalling handle to a peer entity with which a bearer is to be 
established. 

«bearer attributes»; Both functional groups shall exchange the bearer properties (e.g. codec to be used, transport 
protocol to be used) that they shall use to send media. 

«address»; Both functional groups shall exchange the address to which the media may be received. 

Normal behaviour: 

A temporary logical association is established between entities for the purpose of creating a bearer between them. The 
bearer is established within the boundaries of the network functional group. 

The temporary logical association between the entities is removed upon the request of the entities involved. 

Exceptional behaviour: 

If a bearer cannot be established, the requestor of that bearer shall be notified in an appropriate manner. 

If a failure is detected within any domain, the connection shall be removed in each domain involved and any associated 
resources released. The domain that detects the failure shall supply a reason for failure to each other domain. 

The failure mode behaviour for this capability shall always to remove any existing connection and release any 
associated resources. 
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7.2 Bearer negotiation 

Purpose: 

To provide a means to negotiate between functional groups the properties of a bearer during bearer establishment. This 
capability extends the capabilities of "bearer creation". 

Attributes: 

«bearer attributes»; Both functional groups shall provide the alternative attributes of the bearer that they are able to 
use to send media. 

«address»; Both functional groups shall exchange the address to which the media may be received. 

Normal behaviour: 

Provides a means of negotiation of the properties of the bearer while the bearer is established. 

Should a bearer negotiation result in acknowledgement that no bearer with compatible capabilities can be created, the 
requestor of that bearer shall be notified in an appropriate manner. 

Exceptional behaviour: 

The failure mode behaviour for this capability shall always to remove any existing connection and release any 
associated resources. 

7.3 Bearer re-negotiation 

Purpose: 

To provide the means to renegotiate the properties of a bearer after the bearer has been established. This capability 
extends the capabilities of "bearer creation". 

Attributes: 

«bearer attributes»; Both functional groups shall provide the alternative properties of the bearer that they are able to 
use to send media. 

«address»; Both functional groups shall exchange the address to which the media may be received. 

Normal behaviour: 

Bearer re-negotiation shall not cause the termination of an existing flow before the establishment of the newly 
negotiated flow, except where the original flow was terminated other than at the request of a user. 

Provides a means of negotiation of the properties of the bearer after the bearer has been established. 

Should a bearer negotiation result in acknowledgement that no bearer with compatible capabilities can be created, the 
requestor of that bearer shall be notified in an appropriate manner. 

Exceptional behaviour: 

The failure mode behaviour for this capability shall always release any resources acquired during the renegotiation 
process. Should re-negotiation failure result in failure of the call, the release of the bearer shall be initiated from there. 
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7.4 QoS bearer support 

Purpose: 

To support Quality of Service (QoS) for bearers. 

Attributes: 

«media flow type»; The application shall provide the type of media flow required. 

«source address»; The application shall provide the source address for the media flow in the network. 

«destination address»; The application shall provide the destination address for the media flow in the network. 

«QoS service class» or «QoS parameters»; The application shall provide the QoS requirements via QoS Service 
classes as defined in [17] or via QoS parameters (maximum delay, packet loss and peak jitter). 

Normal behaviour: 

The provision of bearers to support media flows with enough resources on the path from the media flow's source and 
destination address to meet the requirements on delay, jitter and loss for the type of media flow used. 

Exceptional behaviour: 

The failure mode of this capability shall be to indicate that the provision of bearers for the desired QoS cannot be met. 

7.5 QoS bearer selection 

Purpose: 

To establish the means of per-bearer QoS selection. This capability extends the bearer creation and bearer 
(re)negotiation. 

Attributes: 

«media flow type»; The application shall provide the type of media flow required. 

«source address»; The application shall provide the source address for the media flow in the network. 

«destination address»; The application shall provide the destination address for the media flow in the network. 

«QoS service class» or «QoS parameters»; The application shall provide the QoS requirements via QoS service 
classes as defined in [17] or via QoS parameters (maximum delay, packet loss and peak jitter). 

Normal behaviour: 

Establishes a temporary association between originating and termination media address upon the request of the 
connectivity control service capability with enough resources on the path from the media flow's source and destination 
address to meet the QoS requirements for the type of media flow used. This association is created in each of the 
functional groups involved. 

Removes the temporary association between originating and termination media address upon the request of the 
connectivity control service capability. This association is removed in each of the functional groups involved. 

If the requested association cannot be established, the connectivity control service capability shall be notified 
appropriately. 

If a failure to establish the requested association is detected within any functional group, the association is to be 
removed in each functional group and any associated resources shall be released. The functional group that detects the 
failure shall supply a reason for this failure to each other functional group and the connectivity control service 
capability. 

Exceptional behaviour: 

The failure mode of this capability shall be to indicate that the desired QoS cannot be met. 
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7.6 Media path optimization 

Purpose: 

To provide a means to allow media to be sent via an optimal path that may be more convenient than that determined by 
call routing. 

NOTE: The definition of optimal is outside the scope of the present document and may be subject to commercial 
and technical considerations. 

Active participation in this capability is optional for any network functional group. 

Attributes: 

«Network functional group Identity»; Each network functional group shall be assigned a globally unique identity for 
use in media path optimization. The service provider identity shall be constructed such that the IP telephony 
administrative domain numbers shall form a valid set of service provider identity values. 

Normal behaviour: 

Each network group, other than one in the terminating network functional group or a terminating gateway, that does not 
actively provide media path optimization capability shall pass any relevant information received in a unmodified form 
to the next, or previous as the case may be, network functional group in the routing of a call. 

Each network group, other than one in the terminating network functional group or a terminating gateway, which does 
actively provide media path optimization capability, shall behave in one of the following ways for each call: 

• pass on relevant information provided by a network functional group which has already taken part in call routing 
unmodified to the next network functional group; or 

• pass on relevant information provided by a network functional group which has already taken part in call routing 
unmodified to the next network functional group in the routing of the call as well as adding the information 
needed to offer media path optimization functions from the present network functional group; or 

• remove, in whole or in part, relevant information offering media path optimization functions which was provided 
by a network functional group which has already taken part in call routing; or 

• remove, in whole or in part, relevant information offering media path optimization functions which was provided 
by a network functional group which has already taken part in call routing as well as adding the information 
needed to offer media path optimization functions from the present network functional group. 

A functional group that passes any information relevant to Media Path optimization functions to the next network 
functional group in the routing of the call shall not request that an optimized media path be established. Media path 
optimization information shall not be passed to a terminating terminal. Functional groups in Intermediate network 
functional groups. Terminating network functional groups or terminating Gateways may request media path 
optimization where permitted. A request for media path optimization is sent to the first functional group that has already 
taken part in the routing of the call. 

A request for a media path optimization shall indicate the service provider identity, chosen by the requesting functional 
group, with which a media path optimization is desired. A request shall also indicate the service provider identity of the 
functional group making the request. 

A request for a media path optimization can only be received by a functional group that is in an intermediate network 
functional group, or is an Originating network functional group or an originating gateway network functional group. 

When an originating network functional group or an originating gateway network functional group receives a request 
for a media path optimization, it shall determine whether the service provider identity is its own. If the offered 
optimized media path is valid and may be provided to the service provider identity by which the request was made, then 
an optimized media path shall be established. 
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A functional group in an intermediate network functional group, which receives a request for an optimized media path, 
shall behave in one of the following ways for each call: 

• pass the request unchanged to the first functional group that has already taken part in the routing of the call; or 

• not pass the request on and establish the media path without an optimized media path. 

All functional groups that pass on a request for media path optimization to a previous network functional group shall 
ensure that any resources are maintained in the event that an optimized media path is not established. When optimized 
media paths are established, any reserved resources shall be released without any undue delay. The period for which 
resources shall be reserved shall be installation dependant with a minimum time established by specification. 

Exceptional behaviour: 

In the case of a fault or loss of data that prevents the proper handling of calls with this feature any network feature 
group which is actively providing optimized media path functions shall remove all relevant information provided by a 
network functional group which has already taken part in call routing from signalling information to be passed to the 
next network functional group in the routing of the call. 



8 Event reporting service capabilities 

8.1 Event recording 

Purpose: 

To record call-related events, including: 

• outgoing calls, whether answered or not; 

• incoming calls, whether answered or not; 

• failed outgoing call attempts; 

• failed incoming call attempts; 

which may form the basis for quality control, network management, metrics, billing and law enforcement activities. 

Attributes: 

«events»; Call related events to be recorded shall include but not be limited to: 

• calling user name (irrespective of the value of the presentation restriction identifier); 

• additional calling user user name (irrespective of the value of the presentation restriction identifier); 

• calling user address; 

• called user name (irrespective of the value of the presentation restriction identifier); 

• called user address; 

• connected user name (irrespective of the value of the presentation restriction identifier) Note: Needed in case the 
call is re-directed; 

• connected user address; 

• calling equipment identifier (e.g. international mobile equipment identity); 

• time/date of call request; 

• time/date of call answer; 

• time/date of call end. 
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Normal behaviour: 

Records call-related events generated within its functional group. 

Event records shall be stored for whatever period is indicated by the needs of operators and law enforcement agencies. 

NOTE: Law enforcement agencies in different countries may have different requirements, which should be 
checked. A period of 12 months could be taken as a rough guide pending further clarification. 

Event records needed for billing, normally successful outgoing calls, shall be stored for the period during which the 
customer is legally able to challenge the bill. 

Exceptional behaviour: 

Should recording not be possible an appropriate reason shall be given. 

9 Application related service capabilities 

This clause defines the behaviour of the service capabilities that relate to simple call service applications as described in 
the present document. Object identifiers for each of these service capabilities in this clause are identified in annex A. 

9.1 Third party authorization 

Purpose: 

Third party authorization applies when a call can only be made with the consent of a party other than either the calling 
user or the called user. The third party may in some cases be an agent of the first party, e.g. charge card or may be an 
intermediary such as a "clearing house". 

Attributes: 

«authorizer»; The requesting party must indicate the identity of an authorizer either by virtue of the called party 
user identity, or part of it, or in the authorizer attribute of the user's user profile. The authorizer attribute shall 
unambiguously identify the authorizing party, the information required and the means by which the request is to be 
made. 

Normal behaviour: 

Network functional groups other than the originating or terminating home functional groups shall take no active part in 
this service capability. 

The need for authorization shall be determined by either the originating or terminating home network functional group, 

as the case may be. 

In the case of the originating home functional group this may be as a result of the user identity request or a service code 
or construct appended or prepended to it. In the case of the originating network functional group it may also be 
determined from the presence of the authorizer attribute in the calling users profile. In the case of the terminating home 
network functional group it may be determined from the presence of the authorizer attribute in the called users profile. 

The authorizer shall be provided with the information related to the call that has been requested. The authorizer shall 
either: 

i) Authorize the call; or 

ii) Authorize the call subject to limits or either time or cost; or 

iii) Refuse the call. 

If a call is refused the user shall receive a normal indication that the call cannot be completed. 

If the call is authorized subject to limits then the limit shall be monitored by the functional group that obtained the 
authorization. The behaviour when a limit is reached is not subject to standardization here except that if a call is 
released as a result the called and calling users shall not receive any indication that the call released other than normally. 
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Exceptional behaviour: 



If the authorizer cannot be reached or fails to respond to a request the behaviour shall be as if the request had been 
refused. 

9.2 Overlap signalling 

Purpose: 

This service capability applies to TIPHON Release 3 where E.164 or private numbering is used as the naming scheme. 
To provide the capability to request and deliver additional called party identifier information. 

Attributes: 

«caUed user identifier»; Additional called party identifier information (if the called party identifier is a number this 
shall take the form of additional digits). 

Normal behaviour: 

If a receiving network functional group does not have enough information to establish the intended destination of a call 
it shall request additional information. When enough information is received this shall be indicated to the originating 
party. 

Any network functional group receiving these requests and indications shall forward them to the originating terminal. 

Exceptional behaviour: 

If additional information is requested but not provided in an acceptable time determined by the policies of the network 
functional group's domain, this shall be indicated to the requesting functional group and the call shall be cleared and all 
resources shall be relinquished. 
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Annex A (normative): 

ASN Object Identifiers for service capabilities 

This clause has been included to identify ASN.l object identifiers for TIPHON Release 3 service capabilities which will 
then allow interconnect agreements to be written. 

ASNUypeModule { ccitt(O) identified-organization (4) etsi(O) tiphon() release3(XXX) asnlModule(O) } 

BEGIN 

tiphonS-Registration-Capabilities OBJECT IDENTIFIER::={ccitt (0) identified-organization (4) etsi (0) tiplnon() 
release3(XXX) registration-capabilities(7) } 

tiplnonS-Service-Capabilities OBJECT IDENTIFIER::={ccitt (0) identified-organization (4) etsi (0) tiplnon() 
release3(XXX) service-capabilities(8) } 

- Registration Service Capabilities 

terminalTransportServiceRegistration OBJECT IDENTIFIER ;:= {tiphonS-Registration-Capabiiities 
terminalTransportServiceRegistration(l)} 

userServiceRegistration OBJECT IDENTIFIER ::= {tiphonS-Registration-Capabilities userServiceRegistration(XX)} 

carrlerSelection OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities carrierSelection (11)} 

- User Profile Access 

userProfile OBJECT IDENTIFIER ::= {tiphonS-Registration-Capabilities userProfile (3)} 

- Call Connectivity Service Capabilities 

simpleCallEstablishment OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities simpleCallEstablishment (1 )} 

callingUserldentityGeneration OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities callingUserldentityGeneration(4)} 

callingUserldentityConveyance OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities 
callingUserldentityConveyance(5)} 

callingUserldentityDelivery OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities callingUserldentityDelivery(6)} 

callRejection OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities anonymousCallRejection(7)} 

numberPortabilityACQ OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities numberPortabilityACQ (8)} 

numberPortabilityOoR OBJECT IDENTIFIER ::= {tiphonS-Sen/ice-Capabilities numberPortabilityOoR (9)} 

numberPortabilityPivot OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities numberPortabilityPivot (10)} 

emergencyCalls OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities emergencyCalls (12)} 

alternativeMediaPath OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities AlternativeMediaPath (19)} 

Bearer Connectivity Service Capabilities 

emergencyCalls OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities emergencyCalls (12)} 
bearerCreation OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities bearerCreation (14)} 
bearerNegotiation OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities bearerNegotiation (15)} 
bearerRe-negotiation OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities bearerRe-negotiation (16)} 
qoSBearerSupport OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities qoSBearerSupport (17)} 
qoSBearerSelection OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities qoSBearerSelection (18)} 
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-- Event Reporting Service Capabilities 

eventRecording OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities eventRecording(2)} 

-- Application Related Service Capabilities 

handlingofPriorltyCalls OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities handlingofPriorityCalls (13)} 

thirdPartyAuthorization OBJECT IDENTIFIER ::= {tiphonS-Service-Capabilities thirdPartyAuthorization (20)} 

overlapSignalling OBJECT IDENTIFIER ::= {tiphon-Service-Capabilities overlapSignalling (XY)} 

END 

END 



£75/ 



39 ETSI TS 1 01 878 V1 .1 .1 (2002-02) 



Annex B (informative): 
Other capabilities 

B.1 Introduction 

This clause covers other capabilities that may be expressed in a form similar to service capabilities but are not normally 
negotiated between networks and do not affect the call control meta-protocol. 

B.2 Lawful interception access 

Purpose: 

To enable the lawful interception of calls where the identity of the target is known to a particular functional group. This 
service capability is required of all network functional groups. The handover interface through which the signalling and 
media information are sent to a relevant authority and the way in which lawful interception is requested are outside the 
scope of this service capability. 

Attributes: 

There are no attributes related to LAwful interception access. 

NOTE: The user should not be able to detect when lawful interception is applied. More information on lawful 
interception is given in TS 101 331 [18] and TR 101 750 [19]. 

Normal behaviour: 

Where a network functional group is notified that a communications for a given user is to be monitored all the 
signalling and media is subject to monitoring. The signalling information is made available to the relevant agency by a 
means that is beyond the scope of this specification. 

When a call set-up involving a notified target is received at a network functional group it shall refuse any request to 
permit an Alternative media path which may be request by other functional groups in the call. 

Signalling information relating to the call shall include information, e.g. IP address, protocols, port numbers etc., which 
are valid for the location at which the intercept point is located. If intercept could be affected at more than one place 
then valid addresses for all places where the functional group can provide intercept information shall be provided. 

Exceptional behaviour: 

None identified. 



B.3 Service resolution for number translation 

Purpose: 

This capability applies to TIPHON Release 3 where E.164 is used as the naming scheme. Its function is to resolve the 
called E.164 number into a translated E.164 number. This resolution is objective, i.e. the result (the translated E.164 
number) is the same irrespective of where the resolution is performed. Thus this service resolution may be implemented 
as a separate service. A service resolution may be used for the support of: 

Non-geographic numbering services such as freephone and premium rate. 

Call re-direction services. 

Personal numbering services. 

NOTE: See TS 101 326 [11] for more information on service resolution. 
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Attributes: 

A user shall supply an E. 164 number as a user identifier corresponding to another user to whom a connection is desired. 

The service resolution shall determine the translated E. 164 number. 

All networks other than the home network of the called party should perform this type of service resolution before a 
service resolution for the home network identity. 

Normal Behaviour: 

A network functional group shall determine whether a service resolution for number translation is required. If it is 
required, network functional group shall determine the translated E.164 number associated with the called E.164 
number. 

When a network functional group has established the translated E.164 number associated with the called E.164 number 
it shall be possible to transfer both the original called E.164 number and translated E. 164 number unambiguously. 

The translated E.164 number shall be used to inform the routing decision at any network functional group where it is 
available. 

Exceptional behaviour: 

When, because of a fault, the translated E. 164 number cannot be determined, routing should proceed as if this service 
resolution were not required. If this means that routing is no longer possible, then a failure indication should be given. 



B.4 Service resolution for destination network identity 

Purpose: 

This capability applies to TIPHON Release 3 where E.164 is used as the naming scheme. Its function is to resolve the 
called E.164 number, or the translated E.164 number if present, into the identity of the destination network. 

• The called E.164 number will be resolved to the home network identity. 

• The translated E. 164 number will be resolved to a visited network identity. 

This resolution is objective, i.e. the result (the destination network identity) is the same irrespective of where the 
resolution is performed. Thus this service resolution may be implemented as a public database service. A service 
resolution may be used for the support of: 

• Number portability. 

• Individual number allocation. 

NOTE: See TS 101 326 [11] for more information on service resolutions. 

Attributes: 

A user shall supply an E. 164 number as a user identifier corresponding to another user to whom a connection is desired. 

The service resolution shall determine the identity of the destination network that serves the called number, or the 
translated E.164 number if present. In addition it may determine the identity of a specific location within that network 
that provides service control for the called number. 

Normal behaviour: 

A network functional group shall determine whether the user identifier of the called party should be queried for service 
resolution. If it should be queried the network functional group shall determine the destination network identity 
associated with the called E.164 number, or the translated E.164 number if present. 

When a network functional group has established the destination network identity associated with the called E. 164 
number it shall be possible to transfer both the unchanged called E.164 number, or the translated E. 164 number if 
present, and the destination network identity unambiguously. 
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The destination network identity shall be used to inform the routing decision at any network functional group where it is 
available. 

Exceptional behaviour: 

When, because of a fault, the destination network identity cannot be determined routing should proceed as if this service 
resolution were not required. If further routing is not possible then a failure indication should be given. 
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Annex C (informative): 
TIPHON functional model 

C.1 Reference model 

The service abstraction layer described in [1] is defined by a modular and extensible set of service capabilities. These 
service capabilities can be distributed over a number of service domains, as has been shown in [1]. These domains that 
must be interconnected so that the distributed capabilities can be combined to make up the end-to-end service 
application. 

This clause introduces a number of concepts necessary to define service capabilities in the context of domains and their 
interconnection. 

TIPHON structures concerns using the concepts of domains and functional groups and are described in this clause. 
These concepts are used throughout the TIPHON Release 3 documentation. 



C.2 Domains 



An administrative domain is defined as a collection of physical or functional entities under the control of a single 
administration. This is a business concepts and only of relevance in TIPHON to scope further definitions. 

A domain is defined as a collection of physical or functional entities within an administrative domain which share a 
consistent set of policies and common technologies. This concept of domain is the basis for TIPHON protocol 
harmonization. A domain exposes a consistent set of interfaces to other domains in an appropriate technology. An 
implementation of this domain with equipment may expose one set of technologies (i.e. protocols) to one domain and 
another set of technologies to another. 

Since administrative domain is a business concept associated with ownership it follows that the "owner" of an 
administrative domain may control one or more domains. 

In TIPHON systems three kinds of domains are identified: end-user domains, service domains and transport domains. 
These are defined as: 

• End-user domain: A collection of physical or functional entities under the control of an End-User, which share a 
consistent set of policies and common technologies. 

• Service domain: A collection of physical or functional entities offering IP telephony services under the control of 
an IP Telephony Service Provider which share a consistent set of policies and common technologies. 

• Transport domain: A collection of transport resources sharing a common set of policies, QoS mechanisms and 
transport technologies under the control of a Transport Network operator. 

The technology within each domain provides a number of functions. It is the behaviour of those functions, which is 
described by service capabilities. 



C.3 Functional groups 



TIPHON groups functions that often occur together in functional groups, functional group is a collection of functional 
entities within a domain. In TIPHON systems functional groups are used to structure the necessary functionality to offer 
IP telephony services across domains. The TIPHON Release 3 architecture described in TS 101 314 [10] contains 
reference points that describe the communication between the functional entities between and within these functional 
groups. 



£75/ 



43 ETSI TS 1 01 878 V1 .1 .1 (2002-02) 

Each domain may contain one or more functional groups. Since a domain is always is part of one administrative 
domain, it is implicit in this hierarchy that a functional group has only one 'owner'. It is the 'owner' who sets the policy 
that is applied to technology to create a domain. The owner also decides which service capabilities shall be provided by 
each functional group. 

functional groups have notions of both ownership and of place in the topology of a call. This means that there is a 
difference between the originator and the terminator and the roles of intermediate functional groups. In order to specify 
Service Capabilities the behaviour is described in terms of ownership and topology but independent of the technology 
so functional groups are used rather than Domains for this purpose. 

functional groups that are used to connect calls from one terminal to another are called network functional groups. In 
some instances a network functional group will be used to originate calls and at other times to terminate them. The 
behaviour required will depend on the location of the network functional group in the call topology. 

For calls involving two parties there will be an originating network functional group and a terminating network 
functional group. It may occur that the originating and terminating network functional groups are in the same domain, 
or even in the same set of equipment, but the general case is still used for specification purposes. 

The behaviour of a functional group is determined by whether it is aware of the service application and hence the 
context in which the service capabilities are being used. 

C.3.1 Types of functional groups 

End-User Domains can have two kinds of functional groups: 



• 



• 



Terminal functional group: a functional group representing all the IP telephony functionality within a user's 
terminal. Terminal functional groups may be classified as originating or terminating based upon their location 
within the topology of a specified call; or 

Terminal Registration functional group: a functional group representing the registration functionality within the 
user's terminal. 



Service Domains can have the following kinds of functional groups: 

• network functional group: a functional group containing the functionality required to establish a call between 
two terminals, a gateway and a terminal or two gateways, network functional groups may be classified as 
Originating or Terminating based upon their location within the topology of a specified call; or 

• Gateway functional group: a functional group containing the functionality of a network functional group also the 
functionality necessary to connect calls to the SCN. Gateway functional groups may be classified as originating 
or terminating based upon their location within the topology of a specified call. 
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